Software transactional memory (STM) systems require a version management mechanism that maintains multiple versions of data modified inside transactions. Two version management approaches exist, each of which has overheads when implemented in software. A first approach is referred to as eager versioning, in which a new data value is written in place and an old value is stored in an undo log in case of rollback. This approach has two overheads: maintaining the undo log on each write and restoring values from the undo log on rollback. Some language-level TM memory models preclude the use of eager versioning because it makes speculative values visible to non-transactional accesses.
A second approach is referred to as lazy versioning, in which new data values are written into a software write buffer and are then copied to their destination locations on commit. This approach has three overheads: maintaining the software write buffer, looking up values in the software write buffer on reads, and copying values from the software write buffer on commit. Lazy versioning can lock written data at either encounter time or commit time, whereas eager versioning can lock only at encounter time. As seen for either approach, significant overhead for version management exists for an STM system.